Split generated code into two types #282
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
konsumlamm
reviewed
Jul 13, 2022
| @@ -382,77 +432,83 @@ macro_rules! bitflags { | |||
| } | |||
| } | |||
|
|
|||
| const _: () = { | |||
There was a problem hiding this comment.
What's the reason for putting this in a const _: () = { ... }?
There was a problem hiding this comment.
It turns out const _: () = { .. } is a great container for code generated by macros because:
- It's supported in any context where other items can be generated. You can write them in modules, functions, and the middle of other expressions.
- It gives us a new scope to define items in. Any types we define in the body of this
constdon't conflict with any outside of it. Any types we define in theconstare also unreachable from outside of it. That's why we've got a trait with an associated type that lets us peek inside. We can even wrap the contents of theconstbody in amodto hide fields if we want.
Co-authored-by: konsumlamm <44230978+konsumlamm@users.noreply.github.com>
Closed
|
cc @konsumlamm @arturoc What do you all think of this new internal library organization? Are you happy with this direction? |
|
I like it! No complaints from me. |
|
looks good to me |
|
Alrighty! I think the only thing remaining before we could consider stabilizing is adding an associated type for the iterator to the I'll do that in a follow-up, then look at publishing a pre-release build. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #168
Closes #155
Closes #218
Closes #263
Closes #228
Following on from #264
Part of #262
This PR is a refactoring of the generated flags types to make the API ownership between us (
bitflags) and them (callers ofbitflags!) clearer. We generate a public type with an API that we can't make a lot of change to outside of theBitFlagstrait, and a private type that can hold trait implementations that users may choose to bubble up publicly.This makes it possible to pick different semantics for traits like
Ord, and add optional support for external libraries likeArbitrary.It comes with some breakage though:
#[derive(Serialize)]impl, you'll need a#[serde(transparent)]attribute to ensure your format doesn't change.#[derive(Debug)], you'll now get your flags wrapped in the name of your type (newtype formatting)..bitsfield is now a.bits()method.We'll need to give this a thorough test once it builds to make sure it's workable for all the places
bitflagsis currently used, but I think this is a promising future direction for the project. Kind of like thelazy_staticcrate, a lot of our old complexity goes away when we don't need to work around some old language limitations.